One thing I wanted to add (if anyone has ideas how) is to make Enter or Return from the <summary> RichText component carry you to the innerBlocks.

Size Change: +3.42 kB (0%)

Total Size: 1.37 MB

_{compressed-size-action}

Yeah I do also like the simplicity of this approach.

However I worry the loss of the design options of the summary element are going to really limit the styling options you can create for the block. At least without having to resort to custom css.

A few blocks have similar challenges where they have distinct elements that can't be styled (e.g. the button and input in the search block), so it might be nice to solve at some point.

This is a solid point, and it's likely to be relevant for various form controls as well. A comments block is never going to be useful without a "Post Comments" button, and the gained simplicity from a flatter structure is commonly going to be useful for these cases.

One idea for how to solve this is in global styles, surfacing the "Summary" element in a theoretical "Elements" panel, a la #47369. CC: @SaxonF

One idea for how to solve this is in global styles, surfacing the "Summary" element in a theoretical "Elements" panel, a la #47369.

I understand most of the elements being at the top-level, as they can be shared between blocks, but I wonder if Summary would make sense. I think it's only ever going to be used in the details block.

Yeah it's not ideal, but maybe it's not too far a stretch in light of something like #44671.

However I worry the loss of the design options of the summary element are going to really limit the styling options you can create for the block. At least without having to resort to custom css.

I'd say the design tools we have cover the 90% of styling cases for the most part; just look at the example screenshots above I took of me flexing it a bit.

I think it's worth the hefty win in usability for a slight loss in that 10%.

I understand most of the elements being at the top-level, as they can be shared between blocks, but I wonder if Summary would make sense. I think it's only ever going to be used in the details block.

I agree, doesn't seem like it fits on the elements front.

The main loss in styling capability seems to be around styling the summary (border/padding etc.).

I've wrapped the inner blocks in a group and styled from there to get some of the more unique designs up above. It's not 100% ideal, but is sensible—and reduces the conflicting "where is this style coming from" issues from the separate Details, Summary and Content blocks in trunk.

Flaky tests detected in 5f6125f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4701706914
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #35176 in specs/editor/various/autosave.test.js

I am not sure this is more intuitive (Please note I am not in any way a UX expert!) and would prefer to see some user testing results. But I am also unsure of how we could test both versions to see which is preferred.

( And before a call for testing can go out I would prefer to see this issue solved: #49679)

First of all I am testing
#45055
through gutenberg.run
I went to the Gutenberg menu and turned on the Details block experiment and then went back to a page.

Looking at:

Reducing the complexities around style conflicts, as there is one block with design tooling—rather than three. Noted in Add Details/summary block #45055 (comment)).

For example, Buttons block does not allow coloring, but the individual Button blocks do. Perhaps we should do the same here. Otherwise you have color and dimensions applied throughout where it's hard to tell what is coming from where.

I believe this should be addressed more in general, as an UX issue that we need to address likely for all of the Block Editor.

Perhaps the child blocks should not have margin and padding, if the parent does. But block spacing would be nice/relevant on the parent block, and content block perhaps.

I do not understand the logic here. As what you say here would also have relevance for the Columns block with the individual child columns. As for the Columns block it would be nice to be able to fully style the parent and child columns.

Those styles should probably be applied to a parent Group block, which would nearly prevent—but greatly reduce—the same sort of styling clipping issues.

There is also a draft PR by @aaronrobertshaw which mentions column child clipping here:
#40925

Clipping is an issue, but clipping is a minor issue in relation to giving the user the opportunity to style the parent and child the way they need to. Clipping in general is also something that needs to be addressed down the road. Right now I believe that Aarons draft PR has not been merged because of the clipping issue. Again it is minor compared to allowing the user to style things in the way they need.

Allowing the Details block itself to be easily selectable. In trunk, you have to first select the child "Details Summary" or "Details Content" blocks, then select the parent from the toolbar.

To me this is setup the same way as selecting the Gallery block. There is no click the Details block and have the parent first selected and then click the inner blocks, so this is a general issue for blocks that have inner blocks. That all blocks with inner blocks the first initial click should be the parent. Click again to select the inner/child blocks.

Styling in importance as I see it when going through this right now.
To be able to style the top parent the Details block itself. - Check that can be done. -
To be able to style the various inner workings of the block. - Check that can be done. -
Thank you.

Removing an extraneous tree level of blocks. as the parent block is the Innerblocks.

It works for me. As it gives the user the opportunity to style different levels of the Details block. There are so many different use cases to how someone would like to use the Details block. The only conflict I see is the clippings and that is not a big issue.

Negating the need for block locking (and therefore additional icons), as the summary will always be at the top of the Details block.

This I do not understand. Details the top parent will always be the top.

Btw the following could be an example for an artsie site using the Details block. Giving the user a lot of ways to style as they choose.

Btw

......and reduces the conflicting "where is this style coming from" issues from the separate Details, Summary and Content blocks in trunk.

This is more of a general issue that design will need to look closer at. Because there will be various blocks that one will be able to style in many different ways as well as levels inner and parent. Example from the Columns block to where the parent and inner columns have been styled.

Instead of limiting the expression of a user it is better to help give hints as to what the user is styling.

Let me know if there is anything else I should share my thoughts on.

Clipping is an issue, but clipping is a minor issue in relation to giving the user the opportunity to style the parent and child the way they need to... Again it is minor compared to allowing the user to style things in the way they need.

The issue of clipping when changing the shape of a block might seem minor at first glance however with the current inserter being in-canvas, clipping content can cause substantial UX issues as the inserter button can be hidden. I'd argue not being able to easily insert additional blocks is a greater problem than adding a border radius to the container.

I agree we should be able to provide border-radius on more blocks while also better handling the clipping and potential UX impacts there. Joen outlines all this in a more elegant and detailed manner over on the relevant PR (#40925 (comment)).

Relative to this PR, I don't have any strong opinion as to whether border-radius should be included in the adopted block supports or not. You can see the block inserter being clipped in the following demo.

So this clipping happens no matter which version of the block that is used? 🤔 But not if the border-radius is on a wrapping group block?

Yes, but, there are issues with that solution too.

Not sure how helpful this feedback is at this stage, but I think we should lean on simplicity as much as possible, not on customization. There's value in getting the ability to have content that con be toggle in the hands of users. It should look like regular content, like a paragraph that can be toggled, not a full fledged accordion that has other implications. More customization would be misleading in that case because people use it to make the collapsed section look like a heading, different from the rest of the content, which would be problematic. Can we reduce it to its most simplest and go from there?

I want to note one thing in reviewing this which we'll want to fix. It maybe my env, but I can't press space inside the summary element:

I reverted back to wrapping the RichText in a summary element (the original method), which resolves this.

And do we consider the border radius clipping to be a bigger issue than this block, or does the border radius need to be removed?

Also removed border radius support.

I think it's ready for another good look.

Code-wise this looks good, but I wonder whether a deprecation should be added now that the details block has been in a plugin release or two. What do you think?

I don't think we need the deprecation.

What about using lessons learnt in regards to the Details block and continue with a Tabs block?
As it is a nice block to also get into Gutenberg.
#34079